1. Field of the Invention
The present invention generally relates to an emulator. More specifically, the present invention is directed to an extensible console emulator for Hyperion Performance Suite interaction.
2. Related Art
The Hyperion Performance Suite (HPS) is a report and document distribution platform (“Hyperion” and Hyperion product names are trademarks of Hyperion in the United States, other countries, or both). More specifically, HPS is enterprise-class query, analysis, and reporting software, based on a scalable foundation for information delivery. It allows users to access, analyze, and distribute information from disparate sources, and to view that data in personalized dashboards.
Administration and use of the HPS is typically performed via a Web browser, although some administrative tasks require server-side Java applications, and some other tasks are possible via scripting and file editing (Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both). Many day-to-day administrative tasks can only be performed via the Web browser interface, some of which can require many clicks and page-loads. This can be time-consuming for menial tasks on either side, but especially for the administrator of an HPS. It is difficult to export system configuration, status, and content information to an accessible format outside this web-based interaction.
Hyperion does, however, provide a Software Development Kit (SDK), written in Java, that can be used to automate some administrative tasks or system interactions. Not all of the HPS functionality is exposed via the SDK, but a large number of interactions are possible.
To take advantage of the SDK, one must develop a Java application that wraps these SDK objects and methods into some usable form. This is typically done on a case-by-case basis, perhaps creating reusable utility objects to wrap SDK functionality, or creating custom objects for very specific HPS interactions. This can be problematic. For instance, while it is possible to start from a similar set of base functionality, the user-interface could be implemented in differing fashions, solutions that might otherwise be reusable might be locked within larger applications, and any base functionality may not be reusable depending on the overall requirements driving the SDK application design.
There is a need, therefore, for an extensible interface that allows for a standard way to wrap HPS SDK code into useful, reusable components that can be interacted with by a user or in batch-mode fashion and for outputting information to a file.